Consider documenting the side effect of this change on existing code that may query _activitypub_object_id meta. For QuoteRequest activities, the _activitypub_object_id now stores the instrument URL instead of the object URL. This is a breaking change in the meta structure. While this is necessary for the new feature, adding a note in the comment about backwards compatibility or migration considerations would be helpful. For instance, any existing code that queries by object URL for QuoteRequest activities will no longer find them.

Performance concern: the query uses two INNER JOINs on postmeta without ensuring indexes exist. WordPress postmeta table has indexes on meta_key but not composite indexes. This query could be slow on sites with large postmeta tables. Consider:

1. Adding a note about potential performance implications
2. Suggesting database indexes if this becomes a frequently called method
3. Exploring alternative approaches like caching or using a more efficient query structure if performance becomes an issue

The query pattern is:

INNER JOIN {$wpdb->postmeta} pm1 ON p.ID = pm1.post_id AND pm1.meta_key = '_activitypub_activity_type'
INNER JOIN {$wpdb->postmeta} pm2 ON p.ID = pm2.post_id AND pm2.meta_key = '_activitypub_object_id'

This results in two table scans on postmeta which could be expensive.

Missing error handling for JSON decode failure. If $inbox_item->post_content contains invalid JSON, json_decode() will return null, causing the fallback path to be used silently. Consider checking for JSON decode errors explicitly:

$activity_object = \json_decode( $inbox_item->post_content, true );
if ( JSON_ERROR_NONE !== \json_last_error() ) {
    $activity_object = null;
}

This makes it clear when the fallback is used due to corrupted data versus a missing inbox item.

The documentation could be more specific about what "object_id" represents for different activity types. The current documentation only mentions QuoteRequest, but doesn't clarify what object_id means for other activities. Consider adding:

 * For QuoteRequest activities, the object_id is the instrument URL (the quote post).
 * For other activities, the object_id is the URL of the activity's object.

This would make it clearer to future developers how this method should be used.

The assignment $activity_object = null; is unnecessary since it's immediately used in a condition at line 150 that checks for null/empty. This line can be removed as $inbox_item result will be checked, and $activity_object is only assigned if the condition passes. If the condition fails, the fallback block at line 155 assigns a value to $activity_object, so the initialization to null serves no purpose.

Incomplete validation: the check ! $post->post_author will pass for posts with post_author = "0" (string zero) which is truthy in PHP, but will fail for legitimate posts with author ID 0. However, more importantly, this doesn't validate that the post author is a valid ActivityPub-enabled user. Consider using Actors::get_by_id() to validate the user exists and is an ActivityPub actor before proceeding, similar to what's done in queue_reject() at line 258.

Consider including 'published' field in the fallback reconstruction for consistency with the test expectations. The test test_delete_uses_inbox_item creates a QuoteRequest with a 'published' field (line 646), and the comment at line 714 states "verify the reject object is a QuoteRequest with proper structure". While not required for the Reject to function, including all original fields in the fallback would maintain better parity with the retrieved inbox version and make the fallback more complete.

Is this a situation where $object_id = object_to_uri( $activity->get_instrument() ?: $activity->get_object() ); could work?

maybe... I was not sure if we can simply always prioritize instrument over object or if I also have to check for a *Request type.

Looks like at least Friendica has a different interpretation of what instrument is 💪

Could this be a WP_Query call instead? It might help with caching

Needs action docs. Do we even need this action?